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Sir: 

I, George M. Levinson, declare as follows: 

1. I am a co-inventor of the subject matter disclosed and claimed in the above-cited 
application. 

2. I have read the Office Action mailed August 30, 2004 in the above-cited application, 
and the Response thereto, and I understand that this Declaration will be filed with the Response. 

3 . My co-inventors, Timothy P. Joyce, Victoria Galliani, and I conceived of the subject 
matter disclosed and claimed in the above-cited application at least as early as July 22, 2002. See 
attached Exhibit A, Requirements Definition for EMSS Version 3.0. This document states, among 

other things, that the "system shall provide a method of assessing and documenting information 
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associated with Environmental monitoring including, but not limited to, collecting microbial counts, 
analyzing, and trending of entered data." 

4. My co-inventors, Timothy P. Joyce, Victoria Galliani, and I were reasonably diligent 
in reducing the invention to practice prior to June 1 9, 2003 . For example, on September 4, 1 992, we 
prepared a "Functional Specification for EMSS Version 3.0." See attached Exhibit B, which 
describes in further detail what the system will do. 

5 . Further, on January 3 , 2003 , Timothy P. Joyce, and an employee (Tony Castellano) of 
the assignee of our invention (Compliance Software Solutions Corp.) under Mr. Joyce's direction, 
prepared a "Functional Specification," a "Requirements Definition," and a "Configuration 
Management Plan." See attached Exhibit C. The "Functional Specification" noted, among other 
things, that the "system shall provide a method of importing/transferring data output from the Becton 
Dickinson Phoenix™ Automated Microbiology System into the Compliance Software Solutions 
Corp Environmental Monitoring Software System using a CFR Part 1 1 compliant data management 
environment." As also noted in Exhibit C, "The Becton Dickinson Phoenix™ Automated 
Microbiology System is intended for rapid identification (ID) and antimicrobial susceptibility testing 
(AST) of significant organisms." Exhibit C also sets forth the "User Requirements/Functional 
Specifications" of the "interface." 

6. At least as early as March 7, 2003, Timothy P. Joyce prepared a system diagram 
showing the system having a "converter" as envisioned by the inventors. See Exhibit D, including 
the computer screen shot showing the date of the diagram as March 7, 2003. 
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7. Mr. Joyce also provided specifications for a port array to a vendor (Millennium 
Electronics, Inc.), and instructed the vendor to prepare a "Network Serial Port Array Software 
Interface Specification" dated June 12, 2003, and prototype that would create an interface between 
Becton Dickinson Phoenix™ Automated Microbiology System (see http://www.difco.com/) and the 
system we developed in accordance with our invention. See attached Exhibit E. Under Mr. Joyce's 
direction, an employee (Tony Castellano) of the assignee of our invention (Compliance Software 
Solutions Corp.) prepared two separate Revision Summaries on May 9, 2003 . See attached Exhibits 
F and G. In Exhibit F, reference is made to the interface between a Becton Dickinson Phoenix™ 
Automated Microbiology System and the system we developed in accordance with our invention. In 
Exhibit G, a further description is made regarding the database objects, and includes further 
reference to the interface between a Becton Dickinson Phoenix™ Automated Microbiology System 
and the system we developed in accordance with our invention. 

8. I contacted counsel regarding the invention on July 1 7, 2003 . Thereafter, Timothy P. 
Joyce and I reviewed patent search results and drafts of the application up until the filing of the 
application on December 30, 2003. 

9. The "port array" or "interface" or "converter" identified in the attached Exhibits is 
referred to as the "universal hub" in the pending patent claims. 

10. All of the above activities took place within the United States. 

11. I have been warned that willful false statements and the like are punishable by fine or 
imprisonment, or both (18 U.S.C. 1001) and may jeopardize the validity of the application or any 
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patent issuing thereon. All statements made herein of my own knowledge are true and that all 
statements made on information and belief are believed to be true. 

Respectfully submitted, 



Dated: December 29, 2004 




George M. Levinson 
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T.Joj{oer\ Date 

G. Levinsofi, Marketing Date 

v; Gallianl, Quality Systems Date 



Overview 



The system shall provide a method of assessing and documenting information associated 
with Environmental Monitoring including, but not limited to, collecting microbial counts, 
analyzing, and trending of entered data. These trends provide valuable insight into the 
effectiveness of decontamination procedures, housekeeping practices, personnel training, 
and the potential for microbial build-up during production. The use of the system will help 
ensure that environmental control systems are operating as intended. 



Features 

SYSTEM REQUIREMENTS 

The software is designed to reside on a local workstation and its database on a network server to: 1) 
take advantage of the out-of-specification e-mail notification using existing mail network, and 2) 
provide multiple workstations access to the same system database. The software can function 
without a network (i.e. with the database and application loaded on a local workstation). 

The equipment recommendations are as follows: 

Workstation: 

■ Pentium or any 32 bit microprocessor - minimum speed 400 MHz 

■ Microsoft Windows 98 Second Edition or higher 

■ 64 MB RAM (minimum) / 1 28 MB RAM recommended 

Server: 

■ Minimum Pentium III 

■ 256 MB RAM (minimum) / 1 .0 GB RAM recommended 

■ MSDE, SQL Server 7.0 or higher, or Oracle 8x or higher installed 
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USER REQUIREMENTS 



The system should should, at a minimum: 
Provide adequate security for the data 

Allow for user-defined security roles to manage user's access to system functions / data 
Allow system users to easily manage the configuration of the areas to be monitored 
Allow for recording of all pertinent information for sampling materials and equipment 
Provide a means of recording all pertinent information for sampling sites, including sample 
identification, dates / times, etc. 

Allow for the management of data according to potential sample incubation / exposure 
periods 

Allow for recording of organism identification data 
Allow for a means of labeling sample containers 

Provide a means of managing the sampling schedule / task lists by area, personnel, etc. 

Provide a means of managing 'second-party' approval / review of recorded data 

Provide 'user-friendly' / efficient methods for recording of all system data 

Provide a means of tracking all modifications to system data (change control / audit) 

Utilize a means of analyzing entered data to notify appropriate personnel upon detection of a 

condition warranting such action 

Provide a means of managing / tracking out-of-specification results from event occurrence 
through conclusion of investigation 

Ensure the data management process is fully CFR part 1 1 compliant 

Provide a comprehensive reporting package for final results allowing users to select graph / 

plot style and query parameters 

Provide a comprehensive reporting package for final results allowing users to select report 
format and query parameters 

Allow for potential 'transfer / export' of managed data to other data formats 
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Date 



Date 



V. Galliani, Quality Systems Date 

Overview 

• Application Security / Management 

o User access 

o System defaults 

o Application 'preset 1 parameters 

• Database Configuration / Management 

o Plant 

o Building 

o Area 

o Location 

o Sample Type 

o Group / Worklist 

• Data Processing 

o Sample taking 

o Initial Data recording 

o Final Data processing 

• Out-of-specification results (including deviation management) 

■ OK results 

■ Isolate identification 
o Data review / approval 

o Data modification 

• Data Output / Reporting 

o User-configurable report (query) parameters 
o User-configurable report (plot) formats 
o 'Standard' (non user-configurable) reports 
o Process utilities (worksheets, labels, etc.) 
o Electronic output 

■ E-mail notifications 

• Out-of-specification results 

• 'Late / missing 1 samples, groups / worklists, etc. 
o Export options (i.e. PDF, etc.) 
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Potential User Scenarios 



Scenario 1: Jon Fishman - Jon is a microbiology technician in your basic pharmaceutical 
manufacturing facility's Quality Control department. Jon doesn't make a whole lot of money and 
is usually burdened with the most menial tasks involving environmental monitoring, including 
taking and identifying the samples (all the while using supplies/equipment that is within 
expiration), ensuring the correct samples/sampling groups are monitored according to their 
scheduled days / processes, incubating the samples, keeping track of the incubation periods of 
stacks of plates (so they are incubated for the correct period of time), counting and recording 
results, and notifying his supervisor when "bad things go happen." Jon also is responsible for 
recording all information associated with the environmental monitoring process for the big bad 
FDA inspector each time monitoring is performed, including sample dates/times, media lots, 
equipment IDs, sample IDs, etc. Jon hates writing on data sheets/in laboratory notebooks and 
would love an easier way to do his job without disrupting his routine or making him work harder 
(with no more pay!) - automating the management of some of Jon's tasks would make him very 
happy, but he has rudimentary technological skills (and that's being kind). He doesn't like to 
type either. 

Scenario 2: Mike Gordon - Mike is Jon's direct supervisor, and manages five other 
microbiology technicians in the Quality Control department. Mike determines the environmental 
monitoring schedule, which areas are monitored and when/by whom, and usually delegates the 
monitoring tasks among his six microbiology technicians. Mike is responsible for reviewing the 
data that is processed/recorded by Jon and the rest of the microbiology technicians for 
completeness/correctness. Mike is also notified when something goes wrong with the 
monitoring process - this includes out-of-specification results, missing/incorrect sampling data 
that needs to be changed, etc. When "bad things go happen," it is Mike's responsibility to 
investigate/interrogate the situation to determine what happened, its impact regarding the 
manufacturing processes associated with the environmental monitoring that has "gone awry," 
determine which actions, if any, need to be taken as a result of the event, and document the 
conclusion/closure of the excursion. Mike is in frequent contact with the operations managers, 
both to find out what is going on in the manufacturing areas (and thus what monitoring needs to 
be done on which days) and to keep them up to speed on the results of "good" and "bad" 
monitoring data. Mike spends a lot of time on the phone with both the operations staff, outside 
vendors (for ordering environmental monitoring supplies), and his boss (Director / Associate 
Director QC), who always wants a "nice, tidy, concise snapshot" of what was going on in 
manufacturing room A during week B while product C was being made. Mike is semi-skilled 
with technology (i.e. he can use charts in Microsoft Excel, even though it takes an ENORMOUS 
amount of time from his day), but isn't afraid of it if it will give him more time for his everyday 
tasks (he doesn't like change much either) and make his life easier in general. 
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Potential User Scenarios (cont.) 



Scenario 3: Page McConnell - Page is the Director of Quality Control and is Mike's boss. 
Page is the guy the Board of Directors, VP's, the "money men !J iook to when the bottom line 
doesn't look as good as they (and their free-spending trophy wives) would hope. Page runs the 
entire QC department - this includes requesting/approving all documentation generated by 
Mike, such as the out-of-specification reports and the "nice, tidy, concise snapshot" reports 
displaying the wonderfully tight grasp Page has on the entire manufacturing facility regarding 
cleanliness. Page likes nothing more than a report which looks like it has been overrun with 
zeroes. In fact, zero is Page's favorite number because the more zeroes he can throw up in his 
environmental monitoring data presentations at monthly board meetings, the less the "money 
men" have to spend on attorneys to protect the company against product recall lawsuits, 
insurance policies, etc. (and thus the more carats in their wives' gold-plated Range Rovers). 
This all makes Page look good, and a potential future candidate for "money man" status during 
the trek up the corporate ladder. Page wouldn't mind helping Mike out with tasks like creating 
the "nice, tidy, concise" reports because, of course, Page was promoted from Mike's position 
not too long ago and knows how hectic the Supervisor's life (or lack thereof) can be. 
Unfortunately, Page's technological savvy pretty much tops out at sending/receiving email (no 
joke - Page often has problems with the concepts of 'Reply' versus 'Reply All'), so the simpler 
the process of creating these "nice, tidy, concise" reports, the more likely Page will start to 
dabble himself instead of bothering Mike. After all, Page is the person the big, bad FDA 
inspector spends all his time with during site visits, and Page would like nothing better than to 
be able to produce data for Mr. FDA as quickly as possible (instead of going through Mike) - 
Page wants to get that inspector off the site before he finds the problems with the manufacturing 
facility that have been buried behind years of data records. 

Scenario 4: Trey Anastasio - Trey is the IT manager, and the majority of Trey's day is taken 
up by answering stupid questions from the myriad of users somehow gainfully employed at the 
manufacturing facility because his staff consists of himself most days. When Trey isn't teaching 
somebody the difference between a file and a folder over the phone, he's roaming the site, 
correcting network settings, updating registry entries, etc., not to mention installing the latest 
"bells and whistles" associated with some software a "money man" read about in this week's 
Fortune magazine. The last thing in the world Trey likes to hear is that a corporate directive is 
coming down about a new software application that will make the Quality Control department 
more productive - not that Trey doesn't like or trust new software (he is in IT), but he doesn't 
need to be responsible for the implementation, maintenance, and support of another 
corporate/department-wide application. Trey is very protective of his "equipment" (not that 
equipment) and, like any good IT guy, likes to keep his network, servers, etc. exactly the same 
once they are working correctly. Unfortunately, the "money men" often make these decisions 
without consulting Trey, and, even though he's a good guy, Trey can be very reluctant to assist 
in the deployment of any new applications (to be honest, Trey gets his feelings hurt pretty easily 
when not consulted by the "bigwigs" and he feels like little more than a technical support guy at 
a small ISP than a guy with 42 different Microsoft certifications). 
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Non-Goals 



Non-Goal 1 : Automated Scheduler - The proposed system will not act as a scheduler for 
managing an existing environmental monitoring program. The system wiii not automaticaiiy (i.e. 
without user input) begin the data management process according to schedules defined within 
the monitoring program. This is not to say, however, that the system won't 'oversee' the daily 
use/tasks performed by the users and potentially notifying the appropriate personnel if a 
scheduled task has not been started (envision a 'watchdog' reminder system). 

Non-Goal 2: Future Modules - The proposed system will not worry about "building in" 
interfaces for functional modules in the conceptual stage, such as managing Media Fill data, 
etc. We will rely on the proper design of the graphical user interface and, especially, the 
database to allow for retrofitting of such add-on functions in the future. 

Non-Goal 3: Windows 95 Compatibility - The proposed system will not worry about 
installations/deployments on machines using Windows 95 as an OS. Anyplace that still has 
Windows 95 machines around has bigger fish to fry. 
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Initial Startup Parameters 



Database Connection Parameters 

* At initial startup, the user will be prompted for the database version (Oracle or SQL 
Server) and its corresponding database connection parameters 

Default User Account Creation 

• At initial startup (following the setting of database connection parameters) the user will 
be prompted to set up a 'SYSTEM 1 user account for access to the application 
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Application Security - Management 



• Application Security / Management 

o User access - Accounts / account management 

■ User accounts should be managed within the application (a separate 
security level from the database / OS security) 

■ A 'synchronization' function between internal (application) security and 
external (database/OS) security should be included 

■ User accounts (internal) will contain a userid and password which will be 
used to validate access to the application (application/GUI level security) 

■ User accounts and their functional access within the application will be 
'configurable' - i.e. using a list of application functions with checkboxes or 
some other selection method to specify which system functions each 
account will have access to 

■ There will be an administrator role (pre-configured) which will be able to 
add, delete, and modify user account parameters 

■ Administrators will have the ability to manually 'disable' user accounts 

■ Passwords will be 'encrypted' within the system (non-viewable, even by 
administrator) 

■ The password change period will be set by an administrator on an 
account-by-account basis (to accommodate temporary employees) 

■ A password expiration date may be set by an administrator 

■ New user accounts will require a change of password at first login 

■ Passwords will have a minimum length of 6 characters and a maximum 
length of 1 5 characters 

■ Passwords may contain a combination of alpha and numeric characters 

■ There should be a system option forcing passwords to contain at least 1 
alpha and 1 numeric character 

■ Passwords will be case-specific 

■ Userids must be unique 

■ User account records will contain the full name manifestation (first and 
last name) 

■ All users should be able to change his/her password at user prompting as 
well (i.e. via a 'Change Password' button) - in this case, the change 
period for this user account should be re-set to the 'beginning' - i.e. a 
User Account Management form 

■ Upon password expiration, the user should be prompted to enter a new 
password 

■ When changing passwords, the user should be prompted to enter old 
password, new password, and to re-enter new password to confirm 
password change 
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Application Security - Management (cont.) 



o User access - Login 

■ The system will require input of a valid userid / password before loading 
the GUI main screen 

■ The system will autofill the login form with the userid from the last 
successful login 

■ If an invalid userid and/or password is input, the system will notify the 
user with a message box that the userid and/or password are invalid 

■ The system will disable a user account after three (3) unsuccessful login 
attempts 

■ The system will notify the administrator upon disabling of an account 

■ A disabled user account must be reinstated by the system administrator 

■ The system will prevent the 'excising' (cut, copy, paste) of the login 
components (userid / password) 
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Environmental Monitoring Site Components 



• The following components should be defined within the system, and each component 
will include the listed parameters: 
o Company / Site (user created) 

■ Description (including address, city, state, zip) 
o Building (user created) 

■ Description 

■ Company / Site 

o Area (Room) (user created) 

■ Description 

■ Building 

■ Classification - may have multiple classifications within an Area 

■ Visual representation 

o Sample Site / Location (user created) 

■ Description (Physical location) 

■ Location reference number 

■ Area 

■ Classification 

■ Site type 

■ Sample type 

■ Alert / action levels 

o Work / Task List (user created) 

■ Description 

■ Frequency 

■ Sample locations / sample types to be monitored 
o Sample Type (user modified)* 

■ Description 

■ Incubation period 

■ Visual representation 

■ Precision (decimal places for results) 

■ List of required fields (input formats) 

■ Result entry options (special processing) 
o Classification (user modified)* 

■ Description 

o Site Type (user modified)* 

■ Description 



* Denotes that the application will come 'pre-configured' with default components / values for 
Sample Type, Classification, and Site Type entries 
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Environmental Monitoring Site Components (cont.) 



• EM Component Configuration 

o Localization options - At startup the program will prompt the user to review the 

default components for Sample Type, Classification, and Site Type for 

correspondence to local (i.e. client SOP) terminology 
o If at startup the program detects there are no EM components, the user will be 

guided through the process of creating components of the environmental 

monitoring site, including company /site, buildings, areas, sample locations 
o The application will allow for the user to modify the components post-initialization 
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Data Processing 

Routine Environmental Monitoring 

• The system should manage the following steps and their associated pieces of 
information of routine environmental monitoring: 

o Prompting the user for input of 'pre-monitoring' information such as media lot / 

equipment ID numbers, operation / process, product lot, etc. 
o Allow for monitoring of pre-defined environmental monitoring 'worklists,' 

individual sampling locations, or a combination of both 
o Creation of data sheets for recording initial / final environmental monitoring data 
o Creation of labels for identifying environmental monitoring sampling supplies 
(plates, etc.) 

o Provide a 'user-friendly' method for recording of all system data (data entry) 
o Allow for management / entry of 'initial' environmental monitoring data including 

sample date / time, sampler identification, etc. 
o Provide a check against entered 'initial' data for validity of data (i.e. data 

formatting, entry of invalid date/time with relation to the 'centralized' system 

clock, etc.) 

o Allow for variable incubation periods for environmental samples 

o Allow for variable exposure periods for environmental samples 

o Allow for management / entry of 'final' environmental monitoring data including 

read date / time, reader identification, final count, etc. 
o Provide a check against entered 'final' data for validity of data (i.e. data 

formatting, entry of invalid date/time with relation to the 'centralized' system 

clock, etc.) 

o Provide a means of analyzing entered results (final counts) versus defined 

specifications for that sample location at the point of data entry 
o Upon detection of an out-of-specification condition regarding entered results, 

notify appropriate personnel of the aberrant event 
o Provide a means of managing / tracking such out-of-specification conditions from 

event occurrence to conclusion / closure of the event 
o Notifying the appropriate management-level personnel whether 'scheduled' 

monitoring has taken place or is in process upon system access 
o Notifying the appropriate management-level users of the status of all in-process 

data, including ownership, process stage, etc. 
o Notifying the appropriate technical-level personnel the status of environmental 

monitoring sample records they 'own' upon system access, including in-process 

records, out-of-specification records, etc. 



OvylvlrL-iMlM^C- Owl 1 VVnixu OULU 1 IUINO wUixr. 




FUNCTIONAL SPECIFICATION FOR EMSS VERSION 3.0 


Document Control No. 
CSSC-052 




Page 11 of 15 



Data Processing (cont.) 



• The system should manage the following aspects of an isolate identification system 
which works in conjunction with the environmental monitoring program 

o Allow for the recording of organism identification data for all pertinent processed 
sample locations 

o Upon detection of an out-of-specification condition regarding identified organism 

(objectionable) results, notify appropriate personnel of the aberrant event 
o Allow for user-defined macroscopic and microscopic organism characteristics 

• The system should manage the completed environmental monitoring information from a 
review / approval standpoint, highlighted by the following; 

o Ensure that system users may not review / approve their own environmental 

monitoring data entries 
o Ensure that only system users with the proper access level can review / approve 

environmental monitoring data entries 
o Allow for authorized users to modify completed environmental monitoring records 

when warranted 

o Ensure that the record modification process requires 'change rationale' or 

equivalent from the authorized user 
o Provide the option to preclude the system from sending out-of-specification 

notifications for completed but not reviewed environmental monitoring data 

records if specified 

o Provide the system option to include completed but not reviewed environmental 
monitoring data records in reports if specified 
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Reporting 



Report package 

• The system should provide a reporting package for final resuiis 

o The users should be allowed to select the report format, including, but not limited 
to: 

■ Line graphs 

■ Bar graphs 

■ Histograms 

o The users should be allowed to select the query parameters, including, but not 
limited to: 

■ Date range (sample, result, review) 

■ Sampler 

■ Building 

■ Area 

■ Location 

■ Sample type 

■ Result status (out-of-specification) 
- Worklist 

■ Process 

■ Media lot 

■ Equipment ID 

■ Product lot 

• The system should provide a reporting package for identified organisms / isolates 

o The users should be allowed to select the report format, including, but not limited 
to: 

■ Line graphs 

■ Bar graphs 

■ Histograms 

o The users should be allowed to select the query parameters, including, but not 
limited to: 

■ Date range (sample, result, review) 

■ Sampler 
* Building 

■ Area 

■ Location 

■ Sample type 

■ Organism 

• Gram stain 

• Out-of-specification organisms (objectionable) 

• Macroscopic results 

■ Worklist 

■ Process 

■ Media lot 

■ Equipment ID 

■ Product lot 
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Reporting (cont.) 



• The system should provide a reporting package for excursions 

o The users should be allowed to select the query parameters, including, but not 
limited to: 

■ Date range (sample, result, review) 

■ Sampler 

■ Building 

■ Area 

■ Location 

■ Sample type 

■ Organism 

■ Worklist 

■ Process 

■ Media lot 

■ Equipment ID 

■ Product lot 

• The system should provide a reporting package for data result status (i.e. in-process, 
complete, reviewed) 

o The users should be allowed to select the query parameters, including, but not 
limited to: 

■ Date range (sample, result, review) 

■ Sampler 

■ Building 

■ Area 

■ Location 

■ Sample type 

■ Organism 
• Worklist 

■ Process 

■ Media lot 

■ Equipment ID 

■ Product lot 
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Data Transfer / Export 



Data Transfer / Export 

• The system should provide the capability to perform poieniiai Transfer / export / retrieval* 
of the system data to other data formats 

o The potential database formats the system should be 'compatible' with include: 

■ Microsoft Excel 

■ Microsoft Access 

■ Oracle 

■ SQL Server 

■ Crystal Reports 
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21 CFR Part 11 



Audit Trail 

• The system should maintain an automatic (non-user modifiable) audit trail of all 
modifications made to the system. The audit trail should contain the following: 

o An entry identifying the type of modification made to the database / record, such 

as additions, deletions, modifications, review, etc. 
o An entry identifying the user performing the modification to the database / record 
o An entry noting the date / time of the database / record modification 
o The date / time included in the audit trail should be retrieved from the server 

system clock, not the local system clock 
o The entire database record being modified with the changed fields highlighted 
o The full manifestation of the name of the user performing the modification 
o The option to add a 'comment' to the audit trail record at the time of database 

record modification 

• The audit records should be accessible only by authorized users 

• The audit records should be able to be selected by date and category (component) 

• The audit records should be reported in an 'easy-to-read ' format (view and print) 

Electronic Signatures 

• The system should have the option to require an electronic signature prior to performing 
any modification to the database / records 

• The electronic signature will require the entry of the username and password of the user 
performing the database modification 

• The electronic signature will provide the option to enter information describing the 
'meaning* of the signing 

• The electronic signature will prevent the 'excising* (cut, copy, paste) of the electronic 
signature components between signings (i.e. a 'link' between the electronic signature 
and its database record) 
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FUNCTIONAL SPECIFICATION 



The system shall provide a method of importing / transferring data output from the Becton Dickinson Phoenix™ Automated Microbiology System into the 
Compliance Software Solutions Corp Environmental Monitoring Software System using a CFR Part 1 1 compliant data management environment. The 
BD Phoenix™ Automated Microbiology System is intended for the rapid identification (ID) and antimicrobial susceptibility testing (AST) of significant 
organisms. 

1 SYSTEM REQUIREMENTS (EMSS) 

The EMSS software is designed to reside on a local workstation and its database on a network server. The software can 
function without a network (i.e. with the database and application loaded on a local workstation). 

The equipment recommendations are as follows: 

Workstation: 

■ Pentium or any 32 bit microprocessor - minimum speed 400 MHz 

■ Microsoft Windows 98 Second Edition or higher 

■ 64 MB RAM (minimum) / 128 MB RAM recommended 

■ NIC (10/100 Ethernet) 

Server: 

■ Minimum Pentium III 

■ 256 MB RAM (minimum) / 1 .0 GB RAM recommended 

■ MSDE, SQL Server 7.0 or higher, or Oracle 8x or higher installed 

2 USER REQUIREMENTS / FUNCTIONAL SPECIFICATIONS (EMSS/PHOENIX INTERFACE) 

The interface should: 

2.1 Ensure that the data transferred (uploaded) from the Phoenix™ to the EMSS retains its data integrity during 
the transfer process 

2.2 Transfers (uploads) the data from the Phoenix™ using RS232 connectivity 

2.3 Assume that the Phoenix™ input Accession ID is the same string value as the EMSS Sample ID 

2.4 Provide for the creation of 'supplemental' Sample ID labels for placing on the Phoenix™ test panels (to 
facilitate entry of Accession ID by Phoenix™ user) 

2.5 Transfers (uploads) the Accession ID, Observation ID, Organism ID, Test ID, Sequence ID, Instrument ID, 
Test Start date, Test Complete date, Data Sent date, and Comments information from the Phoenix™ 

2.6 The Phoenix™ data will be transferred (uploaded) to the EMSS database automatically according to the 
settings on the Phoenix™ Communications Configuration screen (i.e. Solicited, Send on Finalization, Send on 
Completion, Send as Available, Send at Fixed Time) 

2.7 The Accession ID, Observation ID, Organism ID, Instrument ID, and Test Complete date are non-modifiable 
and automatically populated within the EMSS interface (Routine Organism ID form) 

2.8 The Source field within the organism data is automatically populated with Phoenix™ if the organism data in 
question is coming from the Phoenix™ 

2.9 The organism data is subject to the same CFR Part 1 1 / user security level constraints including audit trail, 
change functions, etc. as the environmental monitoring data within EMSS 

2.10 The Phoenix™ data will be accessible in reports, etc. in the same manner as EMSS environmental data 

2.1 1 Provide for data / error management in the event that communication is lost between the Phoenix™ and the 
EMSS database (i.e. transfer/upload queue/buffer, EMSS query of the 3100-record Phoenix™ database, etc.) 

2.12 Provide for data / error management in the event that the transferred (uploaded) Organism ID code does not 
exist in the 'organism library' 
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REQUIREMENTS DEFINITION 



The system shall provide a method of importing / transferring data output from the Becton Dickinson Phoenix™ 
Automated Microbiology System into the Compliance Software Solutions Corp Environmental Monitoring Software 
System using a CFR Part 1 1 compliant data management environment. The BD Phoenix™ Automated 
Microbiology System is intended for the rapid identification (ID) and antimicrobial susceptibility testing (AST) of 
significant organisms. 

1 SYSTEM REQUIREMENTS (EMSS) 

The EMSS software is designed to reside on a local workstation and its database on a network server. The 
software can function without a network (i.e. with the database and application loaded on a local workstation). 

The equipment recommendations are as follows: 

Workstation: 

■ Pentium or any 32 bit microprocessor - minimum speed 400 MHz 

■ Microsoft Windows 98 Second Edition or higher 

■ 64 MB RAM (minimum) / 128 MB RAM recommended 

■ NIC (10/100 Ethernet) 

Server: 

■ Minimum Pentium III 

■ 256 MB RAM (minimum) /1.0 GB RAM recommended 

■ MSDE, SQL Server 7.0 or higher, or Oracle 8x or higher installed 

2 USER REQUIREMENTS (EMSS/PHOENIX INTERFACE) 

The interface should: 

• Ensure that the data transferred (uploaded) from the Phoenix™ to the EMSS retains its data integrity during 
the transfer process 

• Transfers (uploads) the data from the Phoenix™ using RS232 connectivity 

• Assume that the Phoenix™ input Accession ID is the same string value as the EMSS Sample ID 

• Provide for the creation of 'supplemental' Sample ID labels for placing on the Phoenix™ test panels (to 
facilitate entry of Accession ID by Phoenix™ user) 

• Transfers (uploads) the Accession ID, Observation ID, and Organism ID information only from the 
Phoenix™ 

• The Phoenix™ data will be transferred (uploaded) to the EMSS database automatically according to the 
settings on the Phoenix™ Communications Configuration screen (i.e. Solicited, Send on Finalization, Send 
on Completion, Send as Available, Send at Fixed Time) 

• The Accession ID, Observation ID, and Organism ID are non-modifiable and automatically populated within 
the EMSS interface (Routine Organism ID form) 

• The Source field within the organism data is automatically populated with Phoenix™ if the organism data in 
question is coming from the Phoenix™ 

• The organism data is subject to the same CFR Part 1 1 / user security level constraints including audit trail, 
change functions, etc. as the environmental monitoring data within EMSS 

• The Phoenix™ data will be accessible in reports, etc. in the same manner as EMSS environmental data 

• Provide for data / error management in the event that communication is lost between the Phoenix™ and the 
EMSS database (i.e. transfer/upload queue/buffer, EMSS query of the 3100-record Phoenix™ database, 
etc.) 

• Provide for data / error management in the event that the transferred (uploaded) Organism ID code does 
not exist in the 'organism library' 



Product: EMSS Phoenix Interface 


Created By: Tony Castellano & Tim Joyce 


Revision By: N/A 




Version: 1 | Date: 1/3/2003 




| Page 1 of 1 



Configuration Management Plan 

The EMSS Phoenix Interface project will be managed according to the roles stated in item 2.3 in 
SOP QA-402. The members of the project team are Tony Castellano, Tim Joyce, Victoria 
Galliani, Alia Arens, Cindy Jones, and George Levinson. 

The following table lists the roles identified for distribution of project tasks and the team members 
assigned to them: 



PROJECT ROLE DISTRIBUTION 



Roles 


Project Team Members 


Marketing 


George Levinson* 


Program Management 


Tim Joyce* 


Information Systems 


Tony Castellano* 


Quality Assurance 


Victoria Galliani* 


Validation 


Alia Arens, Tony Castellano, Victoria Galliani*, 
Cindy Jones, Tim Joyce*, George Levinson, 
Todd Daniels, Rob Beard 


Installation and Technical Support 


Tony Castellano*, Tim Joyce* 



* Denotes primary member(s) of role 
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Section 1- Overview 

1.1. Target Application 

1.1.1. The network serial port array includes software targeted for use in any Windows operating system 
(XP, 2K, NT, Me, 98, 95) 

1.1.2. The software library encapsulates the network protocol required to interface to the 4-port network 
serial devices in a system and give the user application simple read/write and setup functions for 
interacting with the serial ports. 

1.1.3. The software takes the form of a Microsoft "ActiveX control" which is an object that can easily be 
embedded in a custom Visual Basic application or other forms based application. This includes 
popular HMI software such as LabView and WonderWare. As an extreme example, it could even 
be embedded in a Microsoft Excel spreadsheet running macros. 

1.1.4. ActiveX controls "reveal" their available commands (methods) and properties to the design 
environment for the application being built. For example, the VB Toolbox can be modified to 
include the control, which can then be dropped in to any form. 

1.1.5. For Visual C++ programmers and other developers who prefer to use DLLs instead of ActiveX 
controls, a DLL is also available with identical commands as the ActiveX control. This 
documentation is intended to describe the ActiveX control. 

1.2. Also Included ; 

1.2.1. Sample VB Program: A sample Visual Basic .NET program that simulates a multi-channel text 
terminal is supplied that shows how to use the ActiveX control commands. Complete source code 
is included with step-by-step instructions for how part of it was created. 

1.2.2. A Windows utility that allows the user to detect and configure the Network IP addresses of these 
serial port arrays. 

1.3. Modes of Operation 

1.3.1. The target application must first call setup commands to configure each port that will be used. A 
port is referenced by the IP address of its controller and the port number (0-3) within the 4-port 
array. Each port can be configured differently. 

1.3.2. Configuration options for the ports include Baud-rate, parity start/stop bits etc. But they also 
include special timing and buffering parameters that effect performance of serial-over Ethernet 
communications. The application developer may select to use the default parameters and ignore 
this extra complexity but they are available for fine-tuning of performance. 

1.3.3. Sending data is always done in Non-blocking mode. This means that the function call to send the 
data returns immediately so that the application is not slowed down even though the actual output 
of the serial bytes will not be completed until several milliseconds later (seconds, if the amount is 
large) 

1.3.4. Receiving data is also done in non-blocking mode. Incoming data can be polled by the outer 
application or the ActiveX control can be set up to trigger an "event handler" only when data 
arrives. 
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Section 2. - Commands 

2.1. Setup 

2.1.1. A separate control instance must be added to the application for each separate serial port. The 
port is configured by setting its properties and then by calling the enable method to open the serial 
port. 

2.1.2. Property: BaudRate as Integer 

■ Sets the baud rate for the port. 

■ Type Integer, valid values are 2400, 4800, 9600, 14400, 38400. 

■ Default Value = 9600 

2.1.3. Property IpAddress as String 

■ Indicates the IP address of the 4-port serial controller that owns this port 

■ Valid values are any network IP address in dot notation like '192.168.1.14' 

■ Default Value = None (Most methods will fail if this is not configured) 

2.1.4. Property PhysicalPort as Integer 

■ Indicates the physical port number within the 4-port serial controller. 

■ Default Value = 0, Valid Values 0-3 

2.1.5. Property Parity as integer 

■ Sets Parity handling for the port 

■ 0= No Parity, 1=Odd, 2=Even, 3=Mark, 4=Space 

■ Default value = 0, No Parity 

2.1 .6. Property StopBits as integer 

■ Sets number of stop bits for the port 

■ 1=1 Bit, 2=2 bits, 3=1.5 bits 

2.1 .7. Property RtsControl as integer 

■ Sets the RTS (Request to send line) behavior. Note, this usually has no effect on simple 
RS232 communications. 

■ 0=Always off, 1 = Always On, 2 = On only when transmitting (useful for RS485 converters) 

■ Default = 2 

2.1 .8. Method Enable() As Integer 

■ This enables the serial port with a configuration defined by the properties mentioned above. 
All Send and Receive commands will fail when the port is not enabled successfully. If another 
NetSerial control in the application (or in another application running on the same network) has 
already enabled this same physical port on the controller with this same Ip Address, then this 
call will fail. Jf IpAddress has not been set prior to calling enable, then the call will fail. If any 
other setup property has not been set prior to calling enable, then its default value will be 
used. 
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■ Return Value: 1 if successful, 0 if failed. Call GetErrorCode or GetErrorMsg to see detailed 
information about the failure. 

2.1.9. Method Disable() 

■ This disables the port. All pending send and receive operations are canceled. The 
configuration properties can be changed while the port is disabled and will take effect when re- 
enabled. 

2.2. Sending 

2.2.1 . Sending over the serial ports is always non-blocking. As soon as any of the commands below are 
issued, the data is buffered and the function returns immediately. The buffer is then sent out over 
the serial port. 

2.2.2. It is difficult to have precise control over the bytes in a buffer to be sent in Visual basic String 
handling tools are fooled when a NULL byte is inserted, it is often stripped out. Some string 
handling routines add modify CR\LF character pairs. If this is not a problem, then the SendString 
function can be used to send a string's contents over the serial port. If it is a problem, then the 
SetBuffer and SendBuffer commands can be used to send precisely constructed messages of 
various binary values 

2.2.3. Method SendString (theString as String) AS Integer 

■ This accepts the string contents and adds them to the control's transmit buffer to be sent. The 
function returns immediately without waiting for the transmission to actually be completed. If 
the previous message has not had enough time to be fully sent, then the current message is 
put on the end. If the current message must go out immediately without waiting for prior 
messages, then first call the PurgeTxBuffer method. 

■ Return Value: 1 if successful, 0 if failed. Call GetErrorCode or GetErrorMsg to see detailed 
information about the failure. 

2.2.4. Method SetBuffer (Index AS Integer, theByte AS Byte) 

■ Several of these calls can be used to prepare a buffer to be sent using SendBuffer Index is a 
zero-based offset from the start of the buffer and theByte is placed at that index. If an index is 
skipped in the buffer, then its contents will be whatever was contained there prior to the last 
SendBuffer command. On startup, the buffer contents are initially all zeros. 

2.2.5. Method SendBuffer (Length AS Integer) AS Integer 

■ This sends the first length' bytes of the buffer that was built up using SetBuffer commands. 
The buffer used is a special separate buffer just for this command, it should not be confused 
with the internal transmit buffer. This command behaves just like SendString in how it adds 
the contents to be sent to any existing messages still in the transmit buffer. 

■ Return Value: 1 if successful, 0 if failed. Call GetErrorCode or GetErrorMsg to see detailed 
information about the failure. 

■ Example: The following set of function calls will send the 4-byte sequence 255, 63, 0, 255 
over the serial port. 

- SetBuffer (0,255) 

- SetBuffer (1,63) 

- SetBuffer (2,0) 

- SetBuffer (3, 255) 
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2,3. Receiving 

2.3.1. Receiving from the serial port is also always non-blocking. ReceiveString, ReceiveBuffer, or 
ReceiveByte can be called any time to get whatever incoming bytes have been received in the 
internal receive buffer. These calls return immediately. If nothing has been received then they 
return zero bytes. CountAvailable returns the number of bytes that are available to be retrieved. 

2.3.2. Applications can simply poll incoming bytes by continuously calling ReceiveString or 
ReceiveBuffer. But the control also has the ability to work asynchronously. Applications can take 
advantage of the OnReceiveEvent function, which is called whenever a predetermined number of 
bytes have come in or when a timeout period has expired. The behavior of OnReceiveEvent 
depends on the parameters used in a call to RequestReceive or AlwaysReceive 

2.3.3. Method ReceiveString (MaxLength AS Integer ) As String 

■ This command takes whatever has recently been received in the receive buffer up to 
MaxLength and returns it as a string. If there are more than MaxLength bytes waiting in the 
receive buffer, then these will remain in the buffer after the function call and can be retrieved 
later with another ReceiveString call. 

■ If no bytes are available then an Empty string is returned. 

2.3.4. Method ReceiveBuffer (MaxLength AS Integer) AS Integer 

■ This command takes whatever has recently been received in the receive buffer up to 
MaxLength and copies it to a special buffer where it can be analyzed using calls to 
GetBufferAt. This can be useful for parsing messages that contain bytes, which are not easily 
manipulated as strings in VB. 

■ Returns the number of bytes actually copied and available for use by GetBufferAt commands. 
If nothing has been received lately, then this function returns zero. 

2.3.5. Method ReceiveByte() AS Integer 

■ This returns the next byte in the receive buffer. This can be called repeatedly to read an 
incoming message one byte at a time. When the receive buffer is empty, the integer result is - 
1 (similar to end-of-file). 

■ Returns -1 if there are no more bytes to read, otherwise returns the byte value 0-255. 

2.3.6. Method GetBufferAt( Index AS Integer) AS Integer 

■ This is used after a call to ReceiveBuffer to examine the buffers contents. Index is a zero- 
based offset from the start of the buffer to be returned. Care should be taken not to specify an 
index that is past the number of bytes actually copied in the call to ReceiveBuffer because this 
can return an undefined value. 

■ Returns -1 if the specified index is past the end of what was actually buffered, otherwise 
returns the byte value 0-255. 

2.3.7. Method CountAvailable() AS Integer 

■ This returns the number of bytes waiting in the receive buffer that can be read using 
ReceiveBuffer, ReceiveString, or repeated calls to ReceiveByte. 

2.3.8. Method PurgeRxBuffer() As Integer 

■ This clears any unread contents out of the receive buffer. Thus the next call to ReceiveString 
or ReceiveBuffer will return no new bytes. 

■ Returns the number of unread bytes that were in the buffer before it was cleared. 
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2.4. Asynchronous Receiving 

2.4.1 . Method RequestReceive( Length AS Integer, Timeout AS Integer) 

■ This function tells the control to begin receiving the number of bytes requested by the Length 
parameter and to trigger the application's OnReceiveEvent handler function when they have 
come in. If the specified Timeout value (in milliseconds) elapses before the requested 
number of bytes is received, then the OnReceiveEvent handler is triggered as well. 

■ Within OnReceiveEvent, the application can look at the RequestStatus property to determine if 
the request ended because of a timeout or because all of the requested bytes were received. 
The application can also call CountAvailable to determine how many bytes were actually 
received. If this is less than the number requested, then a timeout can be assumed. 

■ If the Timeout value is zero, this is interpreted as an Infinite timeout. Thus if no bytes come in, 
OnReceiveEvent will never be triggered. 

■ RequestReceive is considered a one-shot function. OnReceiveEvent will only be triggered 
once for each call to RequestReceive. If more bytes come in afterwards, OnReceiveEvent 
will not be triggered again (as they are in AlwaysReceive - see below) If RequestReceive is 
called again before the last call was completed, the last request is simply cancelled. 

2.4.2. Property RequestStatus AS Integer 

■ This property can be read to determine the status of the last RequestReceive command. 

■ 0 = Request is not yet complete. The timeout has not expired and the requested number of 
bytes has not yet been received. 

■ 1 = Requested number of bytes have been received and can be read using ReceiveString etc. 

■ 2 = Timeout expired before the requested number of bytes could be received. 

■ 3 = Communication error with the controller - possibly loss of a network connection or no 
power to the controller. 

2.4.3. Method AlwaysReceive (MaxBlockLength AS Integer, GapTime AS Integer) 

■ This tells the control to begin continuously receiving bytes and continuously notifying the 
application of new arrivals by triggering OnReceiveEvent (see above) 

■ If the bytes come in and then the receive line goes silent for longer than GapTime 
(milliseconds), then this is considered a separate incoming message and OnReceiveEvent is 
triggered. 

■ If bytes are streaming in without a gap, then every time MaxBlockLength bytes have been 
received, OnReceiveEvent is called. 

■ Within OnReceiveEvent, CountAvailable can be called to see how much has actually come in. 
The RequestStatus property will always be 0 unless there is a network problem in which case 
the value will be 3. 

2.4.4. Method StopAlwaysReceive( ) 

■ This cancels the AlwaysReceive mode which may be in progress and stops this from triggering 
OnReceiveEvent until AlwaysReceive or RequestReceive is called again 

2.4.5. Event OnReceiveEvent( ) 
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■ As described in various cases above, this event is triggered in the end application in response 
to AlwaysReceive and RequestReceive commands when requested number of bytes is 
received. 
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Section 3. - Application Development 

3.1 Adding to a VB.NET application 

3.1.1. Run the quick setup program to register the control on the computer being used to develop the 
application. VB will handle redistribution automatically. This will not need to be done on the end- 
user's computer 

3.1 .2. Under the Tools menu, select "Customize Toolbox" 

3.1.3. Under the "Com Components" screen, locate the "NetSerial" control. Click its checkbox, and click 
OK. 

3.1 .4. The NetSerial control should now be available in the Windows Forms pane in the Forms toolbox for 
the visual basic project. 

3.1.5. Add multiple NetSerial controls to one of the Forms in the project. - One for each port that will be 
used. 

3.1.6. Resize these controls to be very small. The control is intended to be non-visible, but if it is left 
visible, it will display a small activity indicator icon when serial communications are taking place. 
Select the control and change its Visible Property to suit. 

3.1.7. View Code for the form and on the select any of the NetSerial components that were just added, 
and then select OnReceiveEvent from the declarations drop list. This adds a serial event handler 
function to the form which will be triggered when non-blocking read/write events are completed for 
that port 

3.1.8. Function calls can be made to any of the NetSerial! member functions for setup, reading, and 
writing. 

- SendBuffer(4) 

3.1 .9. Method PurgeTxBuffer() As Integer 

■ This clears any unsent contents out of the transmit buffer. Thus the next call to SendString or 
SendBuffer will begin sending its contents out immediately. 

■ Returns the number of unsent bytes that were in the buffer before it was cleared. 
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Revision Summary 



• Added the PhoenixLog entity. 

• Added the PhoenixOrganisms entity. 
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Revision Summary 

Added the ThoenixLog' table 
Added the ThoenixOrganisms' table 

Added 'isManualEntry' field to the 'SarnpleTestResultOrganisms' table 



Product: EMS v. 3.0 


Document: Table Definition ERD 


Created By: Cynthia Jones 


Revised By.Tony Castellano 


Version: 22 


Date: 05/09/2003 


Diagram: Security 


Page 1 of 18 





PK 


pk UserlD 


FK1 


fk_RolelD 


U1 


UserName 




Password 




FirstName 




LastName 




Enabled 




PasswordModifiedDate 




PasswordDuration 







PK 


pk RolelD 


U1 


Name 




Security 




Reports 




ConfigureDisplayedText 




Email 




SampleTypes 




Organismldentification 




EquipmentMediaLots 




Settings 




Locations 




TaskLists 




Worklists 




IncompleteSampleTestResults 




CompletedSampleTestResults 




Exceptions 




OrganismReview 




SampleTestResultReview 




ExceptionReview 




Audits 




UniversalDataEntry 









PK.FK1 


cpkfk..ArealD 


PK.FK2 


cpKfK RotelP 













3mmm 


PK 


pk ArwIP 


FK1 


fk.BuildingID 

Reference 

Description 

DiagramFile 
Enabled 

Notes 



Product: EMS v. 3.0 


Document: Table Definition ERD 


Created By: Cynthia Jones 


Revised By:Tony Castellano 


Version: 22 


Date: 05/09/2003 


Diagram: Security 


Page 2 of 18 



Locations 


PK 


pk LopationiP 


U1 


Reference 

Description 

Enabled 

Notes 



Buildings : 


PK 


pk PuildinqlP 


FK1 


fk_LocationlD 
Reference 
Description 
Enabled 

Notes 



Classifications , 


PK 


Pk ciassific^tipniD 




U1 


Name 

Notes 



^ % ; AreaGlassificatiohs 1 , l ' : V ' 


PK,FK1 
PK,FK2 


CDkfk ArealD 


cokfk ClassificationID 











PK 


Dk SamDleSitelD 




FK1,I1 


fk_ArealD 


FK2 


fk_ClassificationlD 


FK3 


fk_SiteTypelD 




Reference 




Description 




ImageFile 




VideoFile 




Enabled 




Notes 



Mm 4^ Areas/, 


PK 


pk ArealP 


FK1 


fk_BuildinglD 




Reference 




Description 




DiagramFile 




Enabled 




Notes 





PK 


pk SiteTypcjIP 




U1 


Name 

Notes 



Product: EMS v. 3.0 


Document: Table Definition ERD 


Created By: Cynthia Jones 


Revised by: Tony Castellano 


Version: 22 


Date: 05/09/2003 


Diagram: EMail 


Page 3 of 18 





PK 


pk EmailQrowpIP 




U1 


Name 
Enabled 



; , .EmaiiAddressesU*. - 


PK 


pk EmailAddres$ID 




U1 


EmailAddress 
FullName 



Product: EMS v. 3.0 


Document: Table Definition ERD 


Created By: Cynthia Jones 


Revised by: Tony Castellano 


Version: 22 


Date: 05/09/2003 


Diagram: Test Levels 


Page 4 of 18 





PK 


pk SampleSitelD 




FK1,I1 


fk_ArealD 


FK2 


fk ClassificationID 


FK3 


fk_SiteTypelD 




Reference 




Description 




ImageFile 




VideoFile 




Enabled 




Notes 



■ v i SampleTestLevels i- ^ 


PK 


pk S?mpl^stLev?||P 




FK1,I1 


fk_SampleSitelD 


FK2J1 


fk_SampleTypelD 




LowerAlert 




UpperAlert 




LowerAction 




UpperAction 




ExceptionWithinRange 


11 


CreationTime 





PK 


Pk §ampl?TypelP 




FK1 


fk_RequiredFieldlD 


FK2 


fkJJnitOfMeasurelD 


U1 


Name 




Primary Temperature 




PrimarylncubationHours 




Secondary Temperature 




SecondarylncubationHours 




Precision 




Res u 1 1 E n t ry O ption 




IconFile 




PassFail 




Enabled 




Notes . J 



Classifications^ * ; 




MM 




PK 


pk ClassificationID 


4 1 


PK.FK1 


cpkfk SamoleTvoelD 


U1 


Name 

Notes 




PK.FK2 


<?pkfk C^S5ificatjpnlD 






LowerAlert 

UpperAlert 

LowerAction 

UpperAction 

ExceptionWithinRange 











Product: EMS v. 3.0 


Document: Table Definition ERD 


Created By: Cynthia Jones 


Revised by: Tony Castellano 


Version: 22 


Date: 05/09/2003 


Diagram: Sample Types 


Page 5 of 18 





PK 


pK Fequir^dFieldlD 




U1 


Name 




Incubator 




MediaLot 




Equipment 




Personnel 




IncubationBy 




SampleTime 




Dynamic 




ExposureMinutes 




IncubationTime 




Process 




ProductCode 




UnitOfMeasure 





PK 


pk SamDleTypelD 




FK1 


fk_RequiredFieldlD 


FK2 


fk_UnitOfMeasurelD 


U1 


Name 




Primary Temperature 




PrimarylncubationHours 




Secondary Temperature 




SecondarylncubationHours 




Precision 




ResultEntryOption 




IconFile 




PassFail 




Enabled 




Notes 





PK 


ok UnitOfMeasurelD 




U1 


Name 



Product: EMS v. 3.0 


Document: Table Definition ERD 


Created By: Cynthia Jones 


Revised by: Tony Castellano 


Version: 22 


Date: 05/09/2003 


Diagram: Task Lists 


Page 6 of 18 





PK 


Dk TaskListID 




U1 


Name 




Frequency Days 




LastUsedTime 




Enabled 




Notes 



mm 


npleTesttevelTaskLists^ , 


PK.FK1 
PK.FK2 


cpKfk Sampl?T?5tLeY?IIP 


QPkfK Ta§KLi§tlD 











PK 


pK .SampleTestLeYeilP 




FK1,I1 


fk_SampleSite!D 


FK2,I1 


fk_SampleTypelD 




LowerAlert 




UpperAlert 




LowerAction 




UpperAction 




ExceptionWithinRange 


11 


CreationTime 



Product: EMS v. 3.0 


Document: Table Definition ERD 


Created By: Cynthia Jones 


Revised by: Tony Castellano 


Version: 22 


Date: 05/09/2003 


Diagram: Work Lists 


Page 7 of 18 





PK 


pK UserlD 


FK1 


fk.RolelD 


U1 


UserName 




Password 




FirstName 




LastName 




Enabled 




Password ModifiedDate 




PasswordDuration 



^. -' EmailGroups u ' " 


PK 


pK EmailQroHpIP 




U1 


Name 
Enabled 





PK 


pk WprKHstlP 


FK1,I1 


fk_CreatorlD 


FK2,I2 


fk_OwnerlD 


FK3 


fk_AlertEmailGroupl D 


FK4 


fk_ActionEmailGrouplD 


FK5 


fk_FollowUpEmailGrouplD 


U1 


Reference 




Description 




InProcess 




CreationTime 



Product: EMS v. 3.0 


Document: Table Definition ERD 


Created By: Cynthia Jones 


Revised by: Tony Castellano 


Version: 22 


Date: 05/09/2003 


Diagram: Sample Test Results 


Page 8 of 1 8 



^ .^^Ijcjuipment V'" : 


PK 


pk EauiomentlD 




U1 


Reference 




Description 




CalibrationDate 




Enabled 




Notes 





PK 


pk MediaLotID 


U1 


Reference 

Description 

Type 

ExpirationDate 
Enabled 

Notes 





& i^WorkListsS3sf%^^ . 


PK 


pk WorkLjstlD 


FK1.I1 


fk_CreatorlD 


FK2.I2 


fk_OwnerlD 


FK3 


fk_AlertEmailGrouplD 


FK4 


fk_ActionEmailGrouplD 


FK5 


fk_FollowUpEmailGrouplD 


U1 


Reference 




Description 




InProcess 




CreationTime 



Incubators : : 


PK 


pk IncubatQrIP 


U1 


Reference 
Description 
CalibrationDate 
Enabled 

Notes 





SarnpleTestResu l^s:f X } f $0$, 


PK 




FK1 M 


fir QamnloToctl ov/olin 
IIV M Oalil|Jlt? 1 colLuVcilu 


FK2 12 


fk WnrklktlD 

1 ff\ VVUI MlOllL/ 


ri\o 


fL' Ins*! iHotnrl O 
IK inCUUdlUilLS 


FK4 


fk FauiDmentlD 


FK5 


fk MpHial nflD 

lr\ IVICU fa l_U U Ly 


FK6 

1 JAW 


fk 5^amolf>rlD 

PIN vJOl 1 ipici 1 


FkT7 


fk Dorcrknnoll Pi 

ir\ rcrsonriciiL' 


1 I \u 


fk InruhatinnRvID 


FWQ 

r r\y 


fir RoaHorin 


FK10 


fk EntrvRvID 

ir\ l_ i in y lj y \ vj 




oampic 




SampleTime 




Dynamic 




ExposureMinutes 




IncubationTime 




Process 




ProductCode 




QuantifiableCondition 




Result 




ReadingTime 4 




UnitOfMeasure 


13 


Completed 




UseResult 




UseAverage 




Pass 




EntryTime 




AlertAction 




Notes 





PK 


pk SampleTestLeveiiD 




FK1,I1 


fk_SampleSitelD 


FK2,I1 


fk_SampleTypelD 




LowerAlert 




UpperAlert 




LowerAction 




UpperAction 




ExceptionWithinRange 


11 


CreationTime 



♦ ♦♦♦♦ 



PK 



FK1,I1 
FK2 



Xce^onRe^i^l^^^^ 



ok SampleTestExceptionReviewlC 



fk_SampleTestResultlD 
fk_ReviewerlD 
ReviewTime 
IsException 





PK 


pk UserlD 


FK1 


fkJRolelD 


U1 


UserName 




Password 




FirstName 




LastName 




Enabled 




PasswordModifiedDate 




PasswordDuration 



Product: EMS v. 3.0 


Document: Table Definition ERD 


Created By: Cynthia Jones 


Revised by: Tony Castellano 


Version: 22 


Date: 05/09/2003 


Diagram: Genus 


Page 9 of 18 



"^.vGenus^ , 


PK 


PK GenusIP 




U1 


Name 
FollowUp 



J. ■ ■ ^mhsu bspecies,p! iA 


PK 


ok SubspeciesID 




U1 


Name 
FollowUp 



Product: EMS v. 3.0 


Document: Table Definition ERD 


Created By: Cynthia Jones 


Revised by: Tony Castellano 


Version: 22 


Date: 05/09/2003 


Diagram: Organisms 


Page 10 of 18 



V, „ , Morphology H ead ings 



U1 



pk MorphologyHeadinglD 



Name 



PK 



FK1,I1 
FK2,I2 

FK3 
FK4 
FK5 
FK6 
FK7 
FK8 
FK9 
FK10 



pk SampleTestResMltlD 



fk_SampleTestLevellD 
fk_WorklistlD 

fkJncubatorlD 

fk_EquipmentlD 

fk_MediaLotlD 

fk_SamplerlD 

fk_PersonnellD 

fkJncubationBylD 

fk_ReaderlD 

fk_EntryBylD 

Sample 

SampleTime 

Dynamic 

ExposureMinutes 

IncubationTime 

Process 

ProductCode 

QuantifiableCondition 

Result 

ReadingTime 

UnitOfMeasure 

Completed 

UseResult 

UseAverage 

Pass 

Entry Time 
AlertAction 

Notes 







5 Morpholpgy 


DescnptK>ns, J: , : ^ ? , 




PK 


pK IVlprpho!ogyPe$criptionlD 




FK1 
U1 


fk_MorphologyHeadinglD 
Name 










)rganis 


iqQMorRholpsi, 






CDkfk QrganismID 

cpkfk MorpholoavDescriptionID 







PK.FK1 
PK.FK2.U1 


CDkfk SamDleTestResultlD 


cpkfk OrganismlP 






IsManualEntry 





PK 


Dk OraanismReviewlD 


FK1.I1 
FK2 


fk_OrganismlD 
fk_ReviewerlD 
ReviewTime 





PK 


pk U?erlP 


. FK1 
U1 


fkJRolelD 

UserName 

Password 

FirstName 

LastName 

Enabled 

PasswordModifiedDate 
PasswordDuration 



PK 



FK1 



ok OraanismID 



fkJdentifierlD 

Reference 

IdentificationDate 

Genus 

Species 

Subspecies 

OrganismCharacteristid 

OrganismCharacteristic2 

OrganismCharacteristic3 

OrganismCharacteristic4 

OrganismCharacteristic5 

OrganismCharacteristic6 

OrganismCharacteristic7 

OrganismCharacteristic8 

OrganismCharacteristic9 

OrganismCharacteristid 0 

OrganismCharacteristid 1 

OrganismCharacteristid 2 

ImageFile 

Active 

Notes 



Product: EMS v. 3.0 


Document: Table Definition ERD 


Created By: Cynthia Jones 


Revised by: Tony Castellano 


Version: 22 


Date: 05/09/2003 


Diagram: Exceptions 


Page 1 1 of 1 8 



| 1 ' ' lr 1 nSa mpleTestResults 


r 
-V 


pk SamoleTestResultlD 


FK1.I1 


fk SampleTestLevellD 


FK2.I2 


fk_WorklistlD 


FK3 


fkJncubatorlD 


FK4 


fk_EquipmentlD 


FK5 


mjviediaLotiD 


FK6 


fk_SamplerlD 


FK7 


fk_PersonnellD 


FK8 


fkJncubationBylD 


FK9 


fk_ReaderlD 


FK10 


fk_EntryBylD 




Sample 




SampleTime 




Dynamic 




ExposureMinutes 




IncubationTime 




Process 




ProductCode 




QuantifiableCondition 




Result 




ReadingTime « 




UnitOfMeasure 


13 


Completed 




UseResult 




UseAverage 




Pass 




Entry Time 




AlertAction 




Notes 



PK 



FK1 



pk QrganismlP 



fkJdentifierlD 

Reference 

IdentificationDate 

Genus 

Species 

Subspecies 

OrganismCharacteristid 

OrganismCharacteristic2 

OrganismCharacteristic3 

OrganismCharacteristic4 

OrganismCharacteristicS 

OrganismCharacteristic6 

OrganismCharacteristic7 

OrganismCharacteristic8 

OrganismCharacteristic9 

OrganismCharacteristid 0 

OrganismCharacteristid 1 

OrganismCharacteristid 2 

ImageFile 

Active 







PK 


pk„^XQ9PtiQnID 






FK1 


fk_SampleTestResultlD 




FK2 


fk_OrganismlD 






ManualException 


< 




ImageFile 






InvestigationNotes 






ActionNotes 






ConclusionNotes 






IsMultipleResult 







PK 


pk ExceotionActlonHistorvID 


FK1,I1 


fk_ExceptionlD 
Name 

ActionPerformed 





PK 


pk ExceptionActionID 




U1 


Name 



Product: EMS v. 3.0 


Document: Table Definition ERD 


Created By: Cynthia Jones 


Revised by: Tony Castellano 


Version: 22 


Date: 05/09/2003 


Diagram: Conductivity 


Page 12 of 18 





PK 


pK 5?mpleTe$tFte5VltiD 




FK1.I1 


fk_SampleTestLevellD 


FK2,I2 


fk_WorklistlD 


FK3 


fkJncubatorlD 


FK4 


fkJEquipmentID 


FK5 


fkJvlediaLotID 


FK6 


fk_SamplerlD 


FK7 


fk_PersonnellD 


FK8 


fkJncubationBylD 


FK9 


fkJteaderlD 


FK10 


fk EntrvBvID 




Sample 




SampleTime 




Dynamic 




ExposureMinutes 




IncubationTime 




Process 




ProductCode 




QuantifiableCondition 




Result 




ReadingTime 




UnitOfMeasure 


13 


Completed 




Use Result 




UseAverage 




Pass 




Entry Time 




AlertAction 




Notes 





PK 


pK CQndHQtiYityResHltID 


FK1,U1 

FK2 
FK3 


fk_Samp!eTestResultlD 

fk_ConductivityTemperaturelD 

fk_ConductivityPHID 

Stagel Result 

Stage2Result 

Stage3Result 

Stagel Pass 

Stage2Pass 

Stage3Pass 



i.^-^Conductivityi?em „ 


PK 


pK Con^wctjvityTemperatyr?iD 




U1 


Temperature 





PK 


ok ConductivitvPHID 




U1 


PH 



Product: EMS v. 3.0 


Document: Table Definition ERD 


Created By: Cynthia Jones 


Revised by: Tony Castellano 


Version: 22 


Date: 05/09/2003 


Diagram: Air Volume 


Page 13 of 18 



S^rnpleTestResults : : 


PK 


ok SamDleTestResultlD 




FK1,I1 


fk_SampleTestLevellD 


FK2,I2 


fk_WorklistlD 


FK3 


fkJncubatorlD 


FK4 


fk_EquipmentlD 


FK5 


fk_MediaLotlD 


FK6 


fk_SamplerlD 


FK7 


fk_PersonnellD 


FK8 


fkJncubationBylD 


FK9 


fkJReaderlD 


FK10 


fk_EntryBylD 




Sample 




SampleTime 




Dynamic 4 




ExposureMinutes 




IncubationTime 




Process 




ProductCode 




QuantifiableCondition 




Result 




ReadingTime 




UnitOfMeasure 


13 


Completed 




UseResult 




UseAverage 




Pass 




Entry Time 




AlertAction 




Notes 





PK 


pk AirVolumelD 


FK1,U1 


f k_Sa m pleTestRes u Itl D 

FlowRate 

SelectedUnitOfMeasure 

ExposureMinutes 

CFUCount 

UseStandardVolume 

CubicFeetReported 
StandardVolume 



Product: EMS v. 3.0 


Document: Table Definition ERD 


Created By: Cynthia Jones 


Revised by: Tony Castellano 


Version: 22 


Date: 05/09/2003 


Diagram: Settings 


Page 14 of 18 



£^*f~," , : LocationSettings t V- 




PK 


Dk SettinalD 


FK1,U1 


fk_LocationlD 




EmailEnabled 




RequireNumbersInPassword 




LatestDateShown 




TimeFormat 




TimeOffset 




Timeout 




xAlert 




yAlert 




Levellnclusive 




FillEsigUserName 




ManualExceptionEnabled 




ReviewBeforeNotify 




ReviewBeforeReport 




DefaultPasswordDuration 




CompanyName 




CompanylmageFile 



Locations^jytf 


PK 


pK UQcationlP 


U1 


Reference 

Description 

Enabled 

Notes 





PK 


pk UserlD 


FK1 
U1 


fk_RolelD 

UserName 

Password 

FirstName 

LastName 

Enabled 

PasswordModifiedDate 
PasswordDuration 















hl^': i '. 1 :' 1 "" . 








PK 


pK Email<3r<?MpiD 




FK1 


fk_LastArchiveBylD 


► 


U1 


Name 




FK2 


fk_SecurityEmailGrouplD 








EsigEnabled 






Enabled 






LastArchiveDate 









Product: EMS v. 3.0 


Document: Table Definition ERD 


Created By: Cynthia Jones 


Revised by: Tony Castellano 


Version: 22 


Date: 05/09/2003 


Diagram: Print History 


Page 15 of 18 





PK 


ok SampleTestResultID 




FK1,I1 


fk_SampleTestLevellD 


FK2,I2 


fk_WorklistlD 


FK3 


fkJncubatorlD 


FK4 


fk_EquipmentlD 


FK5 


fkJVIediaLotlD 


FK6 


fk_SamplerlD 


FK7 


fk_PersonnellD 


FK8 


fkJncubationBylD 


FK9 


fk_Reader!D 


FK10 


fk_EntryByiD 




Sample 




SampleTime 




Dynamic 




ExposureMinutes 




IncubationTime 




Process 




ProductCode 




QuantifiableCondition 




Result 




ReadingTime 




UnitOfMeasure 


13 


Completed 




UseResult 




UseAverage 




Pass 




Entry Time 




AlertAction 




Notes 





PK 


pK PrintHiStQfYlP 


FK1.I1 
FK2.I2 


fk SampleTestResultID 

fk_WorkListlD 

PrintTime 





PK 


ok WorkListID 


FK1.I1 


fk_CreatorlD 


FK2,I2 


fk_OwnerlD 


FK3 


fk_AlertEmailGrouplD 


FK4 


fk_ActionEmailGrouplD 


FK5 


fk_FollowUpEmailGrouplD 


U1 


Reference 




Description 




InProcess 




CreationTime 



Product: EMS v. 3.0 


Document: Table Definition ERD 


Created By: Cynthia Jones 


Revised by: Tony Castellano 


Version: 22 


Date: 05/09/2003 


Diagram: Work List Defaults 


Page 16 of 18 



..... Equipment 


PK 


pk EquipmentID 


U1 


Reference 
Description 
CalibrationDate 
Enabled 

Notes 



PK 



FK1 

FK2 
U1 



pK SempleTypelP 



fkJRequiredFieldID 

fkJJnitOfMeasurelD 
Name 

Primary Temperature 
PrimarylncubationHours 
Secondary Temperature 
SecondarylncubationHours 
Precision 

ResultEntryOption 
IconFile 
PassFail 
Enabled 

Notes 





PK 


pk M^ii^QtlP 


U1 


Reference 

Description 

Type 

Expiration Date 
Enabled 

Notes 



• ■ 1'. - 








PK.FK1 


cpkfk WorkListID 


PK.FK2 


CDkfk SamDleTvDelD 


FK3 


fkJncubatorlD 


FK4 


fk EquipmentID 


FK5 


fkJVIediaLotlD 


FK6 


fk_SamplerlD 


FK7 


fk_PersonnellD 


FK8 


fkJncubationBylD 


FK9 


fk_ReaderlD 




SampleTime 




Dynamic 




ExposureMinutes 




IncubationTime 




Process 




ProductCode 




ReadingTime 




UnitOfMeasure 




AVFIowRate 




AVSelectedUnitOfMeasure 




AVExposureMinutes 




AVStandardVolume 





PK 


pk incubatQrIP 




U1 


Reference 




Description 




CalibrationDate 




Enabled 




Notes 







PK 


pk WorkListID 


FK1,I1 


fk_CreatorlD 


FK2,I2 


fk_OwnerlD 


FK3 


fk_AlertEmailGrouplD 


FK4 


fk_ActionEmailGrouplD 


FK5 


fk_FollowUpEmailGroupl D 


U1 


Reference 




Description 




InProcess 




CreationTime 



4 4 





PK 


pk UserlD 


FK1 


fk_RolelD 


U1 


UserName 




Password 




FirstName 




LastName 




Enabled 




PasswordModifiedDate 




PasswordDuration 



Product: EMS v. 3.0 


Document: Table Definition ERD 


Created By: Cynthia Jones 


Revised by: Tony Castellano 


Version: 22 


Date: 05/09/2003 


Diagram: Label Layouts 


Page 17 of 18 





PK 


pk LabelLayoutID 




U1 


Name 




Barcode 




Sample 




Area 




SampleSite 




WorkList 



Product: EMS v. 3.0 


Document: Table Definition ERD 


Created By: Cynthia Jones 


Revised by: Tony Castellano 


Version: 22 


Date: 05/09/2003 


Diagram: Phoenix 


Page 18 of 18 



, , trffijjf? Phpenixl-og ^ : " 


PK 


pk,..Phoenixi,9glP 




TransmittedTime 
Sequence 
Accession 
Isolate 

OrganismFoundTime 

TestStartedTime 

TestID 

InstrumentID 

Comments 





PK 


PK SpedesIP 






fk_GenuslD 


U1 


Name 




FollowUp 







PK 


pK Phoepi^OrqanismlD 


FK1 


fk_SpecieslD 

OrganismCode 



